In many cases requiring forward error correction, it is desired to use a robust error-correcting code, such as a BCH product code, to provide strong error correction capabilities. Well-known “forward error correction” techniques and codes supplement data intended for one-way transmissions with additional redundant data, to permit the receiver to detect and correct errors up to a predetermined number of errors. The term “forward error correction” is also applied herein to data storage, to permit the retriever of the stored data to detect and correct errors up to a predetermined number of errors. Encoding and decoding according to strong forward error-correcting codes, however, must be done either in software or with complex circuitry. Therefore, where there exist restrictions on the use of software or constraints on the size and complexity of hardware implementations, it may be necessary to use simpler error-detection and error-correction techniques.
As a non-limiting example of the above, data retrieval from a monolithic flash memory exhibits restrictions both on the use of error-correction decoding software and on the complexity of hardware error-correction decoder implementations. At the time of device startup, software loading has not taken place, so decoding cannot be done in software. Moreover, there are strict constraints on the complexity of the hardware circuitry which can be incorporated into the control logic of such devices. Therefore, during device startup, a simple hardware error-correction circuit is needed to bootstrap the software loading so that the more robust decoding can be available for subsequent error detection and correction on retrieved data as well as for error-correction encoding of data to be stored in the device.
This bootstrapping can be done with a code capable of correcting a single-bit error. In the non-limiting examples which are used for illustration in the present application, a Hamming code is employed. For correcting a single bit, only the location of the error is needed, because the magnitude of a bit error is always 1. Thus, without loss of generality, the non-limiting examples in the present application regard only the error location and not the error magnitude. Given the location of an error, it is possible to correct that error by toggling the bit having the specified location. The term “toggling” herein denotes changing a 0-bit into a 1-bit, and vice-versa.
Decoding modern error-correcting codes is typically equivalent to solving the discrete logarithm problem over a polynomial field to derive the error location from a non-zero syndrome. The discrete logarithm problem is believed to be a difficult problem; there is no known general polynomial-time solution for this problem. Instead, there are two practical “brute-force” approaches to solving such a problem, both of which rely on computing a trial syndrome from a trial error location and comparing the trial syndrome with the actual syndrome to determine the actual error location.
The first brute-force approach performs this calculation in real-time using successive trial error locations until the trial syndrome matches the actual syndrome—the final (successful) trial error location is the location of the actual error. The Meggitt decoder is an example of a hardware circuit which uses this first approach. The Meggitt decoder typically has a low gate count, but requires a lot of time to perform the computations and thereby to obtain the error location. As an example, consider a single “sector” of 512 data bytes (4096 bits). For this amount of data, 13 Hamming parity bits are required. The total number of bits is thus 4096+13=4109 bits. Thus, the Meggitt decoder may have to try up to 4109 error locations to find the one matching the given syndrome. On average, the decoder must examine half the memory, or approximately 2055 prospective error locations, before discovering the location of the actual error. This is a highly inefficient use of time.
The second brute-force approach performs the calculation in advance using successive error locations, and saves the results in a table of the error locations for all possible syndromes. Given a syndrome, therefore, a simple lookup in the table obtains the error location immediately. This approach has the advantage of speed but is highly demanding of storage space. For the previous 1-sector example of 512 bytes of data, the table size is determined as follows: The syndrome is 13 bits long, and therefore the table has 213=8192 entries. Recalling that there are 4109 bits of data, it is seen that 13 bits are needed to encode a bit position. Thus, there are 8192 entries, each of which is 13 bits, for a total of 106,496 bits of data in the table. In general, for k syndrome bits, the table size is k*2k bits. This is a highly inefficient use of storage and logic space—a 13 kilobyte table is required for error-correcting half a kilobyte of data.
For regular silicon technology, either of the above approaches is relatively easy and acceptable. However, in the monolithic flash memory with integrated control logic, neither approach is satisfactory. Monolithic flash memory is optimized for the flash memory at the expense of control logic optimization. The result is that the control logic on the integrated chip is slow and of insufficient density to support standard decoding techniques.
There is thus a need for, and it would be highly advantageous to have, a single-bit error-correcting circuit which offers the benefits of both speed and compact hardware implementation. This goal is met by the present invention.